From there, I cover the scanner from a more practical viewpoint. I will differentiate between true scanners are other diagnostic network tools. I will examine different types of scanners, especially very popular ones (such as SATAN and Strobe). At that point, you will gain understanding of what constitutes a scan and what ingredients are necessary to create a scanner.
Finally, you will conduct a scan and analyze what information has been gained from it. In this way, you will derive an inside look at scanner functionality. By the end of this chapter, you will know what a scanner is, how to deploy one, and how to interpret the results from a scan. In short, I will prepare you for actual, network combat using scanners.
Other so-called scanners are merely UNIX network utilities. These are commonly used to discern whether certain services are working correctly on a remote machine. These are not true scanners, but might also be used to collect information about a target host. (Good examples of such utilities are the rusers and host commands, common to UNIX platforms.) Such utilities are discussed later in this chapter.
Cross Reference: rusers gathers information about users currently logged to the targeted host and in this way, closely resembles the UNIX utility finger. host is also a UNIX utility, designed to interactively query name servers for all information held on the targeted host.
You will also require some background in socket programming, a method used in the development of client/server applications.
Cross Reference: There are many resources online to help you get started; I list two here. The first is a bare-bones introduction to socket programming generated by Reg Quinton at The University of Western Ontario. It can be found at http://tecstar.cv.com/~dan/tec/primer/socket_programming.html.Another excellent source for information about socket programming is provided by Quarterdeck Office Systems as an online programming resource. It addresses all supported BSD 4.3 socket routines and is very comprehensive. It is located at http://149.17.36.24/prog/sockets.html.
WARNING: Do not take scanning activity lightly. If you intend to scan wide ranges of domains, check the laws in your state. Certain states have extremely particular legislation. The wording of such statutes is (more often than not) liberally construed in favor of the prosecution. For example, the state of Washington has provisions for computer trespass. (Wash. Rev. Code Sec. 9A.52 110-120.) If you deploy a scanner that attempts to steal the passwd file (a password file on the UNIX platform located in the directory /ETC), you might actually have committed an offense. I will discuss legal issues of hacking and cracking in Chapter 31, "Reality Bytes: Computer Security and the Law."
To understand what scanners do and how they are employed, you must look to the dawn of computer hacking. Transport yourself to the 1980s, before the personal computer became a household item. The average machine had a 10MB hard disk drive and a whopping 640K memory. In fact, our more mature readers will remember a time when hard disk drives did not exist. In those early days, work was done by rotating through a series of 5" floppy diskettes; one for the operating system, one for the current program, and one to save your work.
Those early days are rather amusing in retrospect. Communications were conducted, if at all, with modems ranging in speed from 300 to 1200bps. Incredibly, we got along rather well with these meager tools.
The majority of users had never heard of the Internet. It existed, true, but was populated primarily by military, research, and academic personnel. Its interface--if we could call it that--was entirely command-line based. But these were not the only limitations preventing America from flocking to the Net. Machines that could act as servers were incredibly expensive. Consider that Sun Microsystems workstations were selling for five and six figures. Today, those same workstations--which are scarcely more powerful than a 25MHz 386--command less than $800 on Usenet.
We're talking frontier material here. Civilians with Internet access were generally students with UUCP accounts. Dial-up was bare-bones, completely unlike today's more robust SLIP, PPP, and ISDN access. In essence, the Internet was in its infancy, its existence largely dependent on those early software authors concerned with developing the system.
Security at that point was so lax that some readers will wonder why the Internet was not completely overtaken by crackers. The answer is simple. Today, there are massive online databases and mailing lists that broadcast weaknesses of a dozen different operating systems. Table 9.1 lists a few examples.
| Resource | Location |
| Firewalls mailing list | Firewalls@GreatCircle.COM |
| Sneakers mailing list | Sneakers@CS.Yale.EDU |
| The WWW security list | WWW-security@ns2.rutgers.edu |
| The NT security list | Ntsecurity@ISS |
| Bugtraq | BUGTRAQ@NETSPACE.ORG |
Dozens of such mailing lists now exist on the Internet (for a comprehensive list, see Appendix A, "How to Get More Information"). These lists operate almost completely free of human interaction or maintenance. List members forward their reports via e-mail, and this e-mail is distributed to the entire list, which can sometimes be many thousands of people worldwide. In addition, such lists are usually archived at one or more sites, which feature advanced search capabilities. These search capabilities allow any user, list member, or otherwise to search for inherent vulnerabilities in every operating system known to humankind.
In the beginning, however, there were no such databases. The databases did not exist largely because the knowledge did not exist. The process by which holes get discovered inherently involves the exploitation of such weaknesses. More simply put, crackers crack a machine here and a machine there. By and by, the weaknesses that were exploited in such attacks were documented (and in certain instances, eradicated by later, superior code). This process, as you might expect, took many years. The delay was based in part on lack of knowledge and in part on the unwillingness of many system administrators to admit their sites had been penetrated. (After all, no one wants to publicize that he implements poor security procedures.)
Joining a list: Joining such a list is generally a simple process. Most lists require that you send an e-mail message to a special address. This address accepts commands from your first line of the e-mail message. The structure of this command may vary. In some cases, that command is as simple as subscribe. In other cases, you may be required to issue arguments to the command. One such argument is the name of the list. For example, the Firewalls mailing list at GreatCircle.com requires that you send subscribe firewalls as the first line of your e-mail.Please note that this must be the first line of the e-mail message, and not the subject line. This message is then sent to majordomo@greatcircle.com. The address majordomo is a very common one for processing mailing list subscription requests. Of course, each list is different. To quickly determine the requirements for each security list, I suggest you use Eugene Spafford's Web page as a springboard. Mr. Spafford lists links on his page to most of the well-known security mailing lists.
Cross Reference: Spafford's page is at http://www.cs.purdue.edu/homes/spaf/hotlists/csec-top.html. From Spafford's page, you can get to instructions on how to subscribe to any of the linked lists.
So the stage is set. Picture a small, middle-class community with stately homes and nicely trimmed lawns. It is near midnight. The streets are empty; most of the windows in the neighborhood are dark, their shades drawn tight. One window is brightly lit, though, and behind it is a young man of 15 years; before him is a computer (for the sake of atmosphere, let's label it an old portable CoreData).
The boy is dialing a list of telephone numbers given to him by a friend. These are known UNIX boxes sprinkled throughout a technology park a few miles away. Most of them accept a connection. The common response is to issue a login prompt. Each time the boy connects to such a machine, he tries a series of login names and passwords. He goes through a hundred or more before finally, he obtains a login shell. What happens then is up to him.
It is hard to believe that early cracking techniques involved such laborious tasks. Depending on the operating system and the remote access software, one might have to type dozens of commands to penetrate a target. But, as much as crackers are industrious, they are also lazy. So, early on, the war dialer was developed.
A war dialer consists of software that dials a user-specified range of telephone numbers searching for connectables (machines that will allow a remote user to log in). Using these tools, a cracker can scan an entire business exchange in several hours, identifying all hosts within that range. In this way, the task of locating targets was automated.
Better yet, war dialers record the response they receive from each connect. This data is then exported to a human-readable file. Thus, in neatly written tables, one can tell not only which numbers connected, but also what type of connection was initiated (such as modem, 2400 baud or fax machine).
In essence, scanners operate much like war dialers with two exceptions:
NOTE: The term war dialer reportedly originated from the film WarGames. The film's plot centered around a young man who cracked his way into American military networks. Some people believe that the film was inspired by the antics of the now-famous cracker, Kevin Mitnik. Mitnik was a young teen when he cracked a key military network.
Cross Reference: If you want to check out a war dialer in action, I suggest getting Toneloc. It is freely available on the Internet and is probably the best war dialer ever made. It was written to run in DOS, but it also runs in Windows 95 via command prompt (though perhaps not as smoothly as it should). It is available at ftp://ftp.fc.net/pub/defcon/TONELOC/tl110.zip.
Certain versions of IRIX retained a default login for the line printer. That is, if a user initiated a Telnet session to one of these SGI boxes and logged in as lp, no password would be required.
Typically, the cracker would be dropped to a shell prompt from which he or she could execute a limited number of commands. Most of these were standard shell commands, available to any user on the system. These did not require special privileges and performed only basic functions, such as listing directories, displaying the contents of files, and so forth. Using these commands, crackers could print the contents of the passwd file to the screen. Once they had obtained this display, they would highlight the screen, clip the contents, and paste them into a text editor on their local machine. They would save this information to a local file and subsequently crack the encrypted passwords from the SGI system.
News of this vulnerability spread quickly. Within days, the word was out: SGI WebForce machines could be attacked (and their security compromised) with little effort. For crackers, the next step was to find these machines.
TIP: A number of automated password-cracking utilities exist. Most often, these are designed to crack DES-encrypted passwords, common to UNIX systems. I will cover these utilities in Chapter 10, "Password Crackers."
The FTP directories of these SGI models contained standard, factory-default /etc/passwd files. Contained within these were the login names of system users. The majority of these login names were common to almost any distribution of UNIX. However, these passwd files also included unique login names. Specifically, they contained login names for several utilities and demo packages that shipped with the software. One of these was a login called EZSetup. Thus, a cracker needed only to issue the following search string into any well known search engine:
EzSetup + root: lp:This would return a list of WebForce models. The cracker would then take that list and attempt to crack each machine. It was a quick and dirty way to collect a handful of potential targets. However, that trend didn't last long (about a month or so). Advisories were posted to the Net, explaining that world-readable directories were responsible for the compromise of SGI security. So crackers turned elsewhere.
Some used the InterNIC database to find such machines (the WHOIS service). The WHOIS service, housed at internic.net, is a database of all registered machines currently on the Internet. One can query this database (to find out the network numbers or the owner's address of a given machine) by issuing a WHOIS instruction at a UNIX command prompt. The structure of such a command is whois mci.net. For those who do not use UNIX, one can either Telnet directly to InterNIC (internic.net) or use one of the utilities described later in this chapter.
Many hosts included words within their registered names that suggested at least a fleeting probability that they owned an SGI, such as
Some InterNIC entries also include the operating system type being run on the host. Thus, a search for the string IRIX could reveal a few machines. However, these methods were unreliable. For example, many versions of IRIX did not suffer from the lp bug (neither did every WebForce model). So, instead, many crackers employed scanners.
Trying 199.200.0.0 Connected to 199.200.0.0 Escape Character is "]" IRIX 4.1 Welcome to Graphics Town! Login:The resulting information would be written to a plain text file for later viewing.
Talented crackers would write an ancillary program to automate the entire process. Here are the minimum functions that such a program would require:
Of course, this is a very primitive example, but it illustrates how potential targets are sometimes found with scanners. Now I want to get more specific. Momentarily, you will examine various scanners currently available on the Internet. Before that, however, you need to distinguish between actual scanners and network utilities that are not scanners.
TIP: If you know of an SGI machine and you want to view the IP address of the last person who exploited this vulnerability, finger lp@the.sgi.box. This author traced down a person at Texas A&M University who was compromising machines from Los Angeles to New York using this technique. This young man's originating address appeared on 22 machines. (Some of these were of well- known institutions. While we cannot identify them here, one was a graphic design school in New York City. Another was a prominent gay rights organization in Los Angeles. To this day, these machines may well be vulnerable to such an attack. Alas, many SGI users are gifted graphic artists but have little background in security. A renowned university in Hawaii missed this hole and had an entire internal network torn to pieces by a cracker. He changed the root passwords and destroyed valuable data.)
NOTE: If you currently have a WebForce model, you can test whether it is vulnerable to this simple attack. First, Telnet to the machine. When confronted with a login prompt, enter the string lp and press Enter. If you are immediately logged into a shell, your machine is vulnerable. If so, this can be quickly remedied by opening the file /etc/passwd and inserting an asterisk between the first and second fields for the user lp. Thus, the leading portion of the line would look like this:lp:*:4:7:lp:/var/spool/lpd:instead of like this:lp::4:7:lp:/var/spool/lpd:The idea is to create a locked login. If you fail to do so, the problem will remain because the system is configured to accept a line printer login without requesting a password.
Because we are focusing on scanners, I would like to take a moment to illustrate the distinction. This will serve two purposes: First, it will more clearly define scanners. Second, it will familiarize you with the rich mixture of network resources available on the Internet.
The network utilities discussed next run on a variety of platforms. Most of them are ported from UNIX environments. Each utility is valuable to hackers and crackers. Surprisingly, garden-variety network utilities can tell the user quite a bit, and these utilities tend to arouse less suspicion. In fact, many of them are totally invisible to the target host. This is in sharp contrast to most scanners, which leave a large footprint, or evidence of their existence, behind. In this respect, most of these utilities are suitable for investigating a single target host. (In other words, the majority of these utilities are not automated and require varying levels of human interaction in their operation.)
host ranks as one of the ten most dangerous and threatening commands in the gamut. To demonstrate why, I pulled a host query on Boston University (BU.EDU). The command line given was
host -l -v -t any bu.eduThe output you are about to read is astonishing. A copious amount of information is available, including data on operating systems, machines, and the network in general. (Also, if you are deep into security, some preliminary assumptions might be made about trust relationships.) Examine a few lines. First, let's look at the basic information:
Found 1 addresses for BU.EDU Found 1 addresses for RS0.INTERNIC.NET Found 1 addresses for SOFTWARE.BU.EDU Found 5 addresses for RS.INTERNIC.NET Found 1 addresses for NSEGC.BU.EDU Trying 128.197.27.7 bu.edu 86400 IN SOA BU.EDU HOSTMASTER.BU.EDU( 961112121 ;serial (version) 900 ;refresh period 900 ;retry refresh this often 604800 ;expiration period 86400 ;minimum TTL ) bu.edu 86400 IN NS SOFTWARE.BU.EDU bu.edu 86400 IN NS RS.INTERNIC.NET bu.edu 86400 IN NS NSEGC.BU.EDU bu.edu 86400 IN A 128.197.27.7This in itself is not damaging. It identifies a series of machines and their name servers. Most of this information could be collected with a standard WHOIS lookup. But what about the following lines:
bu.edu 86400 IN HINFO SUN-SPARCSTATION-10/41 UNIX PPP-77-25.bu.edu 86400 IN A 128.197.7.237 PPP-77-25.bu.edu 86400 IN HINFO PPP-HOST PPP-SW PPP-77-26.bu.edu 86400 IN A 128.197.7.238 PPP-77-26.bu.edu 86400 IN HINFO PPP-HOST PPP-SW ODIE.bu.edu 86400 IN A 128.197.10.52 ODIE.bu.edu 86400 IN MX 10 CS.BU.EDU ODIE.bu.edu 86400 IN HINFO DEC-ALPHA-3000/300LX OSF1Here, we are immediately aware that a DEC Alpha running OSF/1 is available (ODIE.bu.edu). And then:
STRAUSS.bu.edu 86400 IN HINFO PC-PENTIUM DOS/WINDOWS BURULLUS.bu.edu 86400 IN HINFO SUN-3/50 UNIX (Ouch) GEORGETOWN.bu.edu 86400 IN HINFO MACINTOSH MAC-OS CHEEZWIZ.bu.edu 86400 IN HINFO SGI-INDIGO-2 UNIX POLLUX.bu.edu 86400 IN HINFO SUN-4/20-SPARCSTATION-SLC UNIX SFA109-PC201.bu.edu 86400 IN HINFO PC MS-DOS/WINDOWS UH-PC002-CT.bu.edu 86400 IN HINFO PC-CLONE MS-DOS SOFTWARE.bu.edu 86400 IN HINFO SUN-SPARCSTATION-10/30 UNIX CABMAC.bu.edu 86400 IN HINFO MACINTOSH MAC-OS VIDUAL.bu.edu 86400 IN HINFO SGI-INDY IRIX KIOSK-GB.bu.edu 86400 IN HINFO GATORBOX GATORWARE CLARINET.bu.edu 86400 IN HINFO VISUAL-X-19-TURBO X-SERVER DUNCAN.bu.edu 86400 IN HINFO DEC-ALPHA-3000/400 OSF1 MILHOUSE.bu.edu 86400 IN HINFO VAXSTATION-II/GPX UNIX PSY81-PC150.bu.edu 86400 IN HINFO PC WINDOWS-95 BUPHYC.bu.edu 86400 IN HINFO VAX-4000/300 OpenVMSI have omitted the remaining entries for sake of brevity. The inquiry produced a plain text file of some 70KB (over 1500 lines in all).
The point here is this: Anyone, with a single command-line, can gather critical information on all machines within a domain. When crackers looks at the preceding information, they are really seeing this:
A host lookup takes less than three seconds, even when the network is under heavy system load. It is quick, legal, and extremely revealing.
CAUTION: There are various ways to protect against this. One way is to run a firewall. Another is to restrict queries of name servers to a particular set of addresses. Another is to completely disallow outside access to your name servers.
This utility can be used to identify the location of a machine. Suppose, for example, that you are trying to track down an individual who posted from a box connected to his or her ISP via PPP. Suppose that the posting revealed nothing more than an IP address that, when run through a WHOIS search, produces nothing (that is, the address is not the address of a registered domain). You can find that machine by issuing Traceroute requests. The second to last entry is generally the network from which the activity originated. For example, examine this Traceroute trace going from a machine in France (freenix.fr) to mine:
NOTE: Man pages are manual pages on the UNIX platform. These are the equivalent of help files. They can be called from a command prompt or from a windowed system. On a full install of UNIX, these man pages cover help on all commands one can issue from a prompt. They also cover most programming calls in C and C++.
1 193.49.144.224 (193.49.144.224) 3 ms 2 ms 2 ms 2 gw-ft.net.univ-angers.fr (193.49.161.1) 3 ms 3 ms 3 ms 3 angers.or-pl.ft.net (193.55.153.41) 5 ms 5 ms 5 ms 4 nantes1.or-pl.ft.net (193.55.153.9) 13 ms 10 ms 10 ms 5 stamand1.renater.ft.net (192.93.43.129) 25 ms 44 ms 67 ms 6 rbs1.renater.ft.net (192.93.43.186) 45 ms 30 ms 24 ms 7 raspail-ip2.eurogate.net (194.206.207.18) 51 ms 50 ms 58 8 raspail-ip.eurogate.net (194.206.207.58) 288 ms311 ms 287 ms 9 * Reston.eurogate.net (194.206.207.5) 479 ms 469 ms 10 gsl-sl-dc-fddi.gsl.net (204.59.144.199) 486 ms 490 ms 489 ms 11 sl-dc-8-F/T.sprintlink.net (198.67.0.8) 475 ms * 479 ms 12 sl-mae-e-H2/0-T3.sprintlink.net (144.228.10.42)498 ms 478 ms 13 mae-east.agis.net (192.41.177.145) 391 ms 456 ms 444 ms 14 h0-0.losangeles1.agis.net (204.130.243.45)714 ms 556 ms714 ms 15 pbi10.losangeles.agis.net (206.62.12.10) 554 ms 543 ms 505 ms 16 lsan03-agis1.pbi.net (206.13.29.2) 536 ms 560 ms * 17 * * * 18 pm1.pacificnet.net (207.171.0.51) 556 ms 560 ms 561 ms 19 pm1-24.pacificnet.net (207.171.17.25) 687 ms 677 ms 714 msFrom this, it is clear that I am located in Los Angeles, California:
pbi10.losangeles.agis.net (206.62.12.10) 554 ms 543 ms 505 msand occupy a place at pacificnet.net:
pm1.pacificnet.net (207.171.0.51) 556 ms 560 ms 561 msTraceroute can be used to determine the relative network location of a machine in the void.
Note that you needn't have UNIX (or a UNIX variant) to run Traceroute queries. There are Traceroute gateways all over the Internet. And, although these typically trace the route only between the Traceroute gateway and your target, they can at least be used to pin down the local host of an IP address.
Cross Reference: Try the Traceroute gateway at http://www.beach.net/traceroute.html.
gajake snark.wizard.com:ttyp1 Nov 13 15:42 7:30 (remote) root snark.wizard.com:ttyp2 Nov 13 14:57 7:21 (remote) robo snark.wizard.com:ttyp3 Nov 15 01:04 01 (remote) angel111 snark.wizard.com:ttyp4 Nov14 23:09 (remote) pippen snark.wizard.com:ttyp6 Nov 14 15:05 (remote) root snark.wizard.com:ttyp5 Nov 13 16:03 7:52 (remote) gajake snark.wizard.com:ttyp7 Nov 14 20:20 2:59 (remote) dafr snark.wizard.com:ttyp15Nov 3 20:09 4:55 (remote) dafr snark.wizard.com:ttyp1 Nov 14 06:12 19:12 (remote) dafr snark.wizard.com:ttyp19Nov 14 06:12 19:02 (remote)As an interesting exercise, compare this with finger information collected immediately after:
user S00 PPP ppp-122-pm1.wiza Thu Nov 14 21:29:30 - still logged in user S15 PPP ppp-119-pm1.wiza Thu Nov 14 22:16:35 - still logged in user S04 PPP ppp-121-pm1.wiza Fri Nov 15 00:03:22 - still logged in user S03 PPP ppp-112-pm1.wiza Thu Nov 14 22:20:23 - still logged in user S26 PPP ppp-124-pm1.wiza Fri Nov 15 01:26:49 - still logged in user S25 PPP ppp-102-pm1.wiza Thu Nov 14 23:18:00 - still logged in user S17 PPP ppp-115-pm1.wiza Thu Nov 14 07:45:00 - still logged in user S-1 0.0.0.0 Sat Aug 10 15:50:03 - still logged in user S23 PPP ppp-103-pm1.wiza Fri Nov 15 00:13:53 - still logged in user S12 PPP ppp-111-pm1.wiza Wed Nov 13 16:58:12 - still logged inInitially, this information might not seem valuable. However, it is often through these techniques that you can positively identify a user. For example, certain portions of the Internet offer varying degrees of anonymity. Internet Relay Chat (IRC) is one such system. A person connecting with a UNIX-based system can effectively obscure his or her identity on IRC but cannot easily obscure the IP address of the machine in use. Through sustained use of both the finger and rusers commands, you can pin down who that user really is.
Nevertheless, this explanation doesn't reveal the value of these utilities in relation to cracking. In the same way that one can finger a user, one can also finger several key processes. Table 9.2 contains some examples.
NOTE: finger and rusers are extensively discussed in Chapter 13, "Techniques to Hide One's Identity." Nonetheless, I'd like to provide a brief introduction here: finger and rusers are used to both identify and check the current status of users logged on to a particular machine. For example, you can find out the user's real name (if available), his or her last time of login, and what command shell he or she uses. Not all sites support these functions. In fact, most PC-based operating systems do not without the installation of special server software. However, even many UNIX sites no longer support these functions because they are so revealing. finger and rusers are now considered security risks in themselves.
| Process | Purpose |
| lp | The Line Printer daemon |
| UUCP | UNIX to UNIX copy |
| root | Root operator |
| The Mail System daemon |
By directing finger inquiries on these accounts, you can glean valuable information about them, such as their base directory as well as the last time they were used or logged in.
Thus, rusers, when coupled with finger, can produce interesting and often revealing results. I realize, of course, that you might trivialize this information. For, what value is there in knowing when and where logins take place?
In fact, there are many instances in which such information has value. For example, if you are truly engaged in cracking a specific system, this information can help you build a strong database of knowledge about your target. By watching logins, you can effectively identify trust relationships between machines. You can also reliably determine the habits of the local users. All these factors could have significant value.
NetScan Tools The NetScan Tools suite contains a series of UNIX utilities ported to Windows 95. Its development team claims that by utilizing ping, network administrators can identity unauthorized machines utilizing IP addresses on their subnets. The program also contains ports of WHOIS, finger, ping, and Traceroute.
Network Toolbox Network Toolbox is very similar to the Netscan Tools suite. It consists of a port of nine separate UNIX utilities. This utility has an interesting feature called IP Address Search, which allows the user to search for machines within a given range of IP addresses. Otherwise, it has the usual fare: finger, DNS, WHOIS, and so on. One special amenity of this suite is that it is exceedingly fast. This utility is discussed in greater detail later in this chapter.
Cross Reference: The Netscan Tools suite is shareware and is available at http://www.eskimo.com/~nwps/index.html.
TCP/IP Surveyor This tool is quite impressive; not only does it gather information about networks and reachable machines, it formats it into a graphical representation that maps routers, workstations, and servers.
Cross Reference: You can find Network Toolbox at http://www.jriver.com/netbox.html.
Cross Reference: TCP/IP Surveyor is shareware and can be found at ftp://wuarchive.wustl.edu/systems/ibmpc/win95/netutil/wssrv32n.zip.
MacTCP Watcher This utility provides ping, DNS lookups, and general monitoring of connections initiated by protocols within the TCP/IP suite.
Query It! Query It! is a solid utility that performs basic nslookup inquiries. It generates information that is very similar to that generated using the host command.
Cross Reference: As of version 1.12, this utility has been designated freeware. However, by the time this book is printed, that situation might change. Get it at http://www.share.com/share/peterlewis/mtcpw/.
WhatRoute WhatRoute is a port of the popular UNIX utility Traceroute.
Cross Reference: Get Query It! at http://www.cyberatl.net/~mphillip/index.html#Query It!.
Cross Reference: WhatRoute is a freeware program and is available at various locations on the Internet, including http://homepages.ihug.co.nz/~bryanc/.
These utilities will always be available to users, even if scanners are not. Moreover, because the Internet is now traveled by more and more new users, utilities to analyze network connections will be commonplace on all platforms.
Cross Reference: For those interested in studying the fine points of TCP/IP implementation on AS/400, I highly recommend the white paper "TCP/IP Connectivity in an AS/400 Environment" by David Bernard. (News/400. February 1996.) It can be found at http://204.56.55.10/Education/WhitePapers/tcpip/tcpip.htm.
NSS differs from its counterparts in several ways, the most interesting of which is that it's written in Perl. (SATAN is also partially written in Perl. ISS and Strobe are not.) This is interesting because it means that the user does not require a C compiler. This might seem like a small matter, but it's not. Crackers and hackers generally start out as students. Students may acquire shell accounts on UNIX servers, true, but not every system administrator allows his or her users access to a C compiler. On the other hand, Perl is so widely used for CGI programming that most users are allowed access to Perl. This makes NSS a popular choice. (I should explain that most scanners come in raw, C source. Thus, a C compiler is required to use them.)
Also, because Perl is an interpreted (as opposed to compiled) language, it allows the user to make changes with a few keystrokes. It is also generally easier to read and understand. (Why not? It's written in plain English.) To demonstrate the importance of this, consider the fact that many scanners written in C allow the user only minimal control over the scan (if the scanner comes in binary form, that is). Without the C source code, the user is basically limited to whatever the programmer intended. Scanners written in Perl do not generally enforce such limitations and are therefore more easily extensible (and perhaps portable to any operating system running Perl 4 or better).
NSS was reportedly written on the DEC platform (DecStation 5000 and Ultrix 4.4). It generally works out the box on SunOS 4.1.3 and IRIX 5.2. On other platforms, it may require basic or extensive porting.
The basic value of NSS is its speed. It is extremely fast. Routine checks that it can perform include the following:
As you might guess, some or most of these checks (except the Hosts.equiv query) can be conducted by hand by any user, even without root privileges. Basically, NSS serves the same function as most scanners: It automates processes that might otherwise take a human weeks to complete.
NOTE: NSS will not allow you to perform Hosts.equiv unless you have root privileges. If this is a critical issue and you do not currently have root, you might want to acquire a copy of Linux, Solaris X86, or FreeBSD. By getting one of these operating systems and installing it at home, you can become root. This is a common problem with several scanners, including SATAN and certain implementations of Internet Security Scanner.
NSS comes (most often) as a tarred, g'zipped file. (In other words, it is a zipped archive created with gzip.exe, a popular compression tool similar to pkzip.exe.) With the original distribution, the author discussed the possibility of adding greater functionality, including the following features:
TIP: If your Perl include directory (where the Perl include files are located) is obscure and not included within your PATH environment variable, you will have to remedy that. Also, users should note that NSS does require the ftplib.pl library package.
Cross Reference: You can find a copy of NSS, authored by Douglas O'Neal (released March 28, 1995) at http://www.giga.or.at/pub/hacker/unix. This location was reliable as of November 20, 1996.
The key feature of Strobe is that it can quickly identify what services are being run on a given target (so quickly, in fact, that it takes less than 30 seconds to pin down a server, even with a 28.8 modem connection to the Internet). The key drawback of Strobe is that such information is limited. At best, a Strobe attack provides the cracker with a rough guideline, a map of what services can be attacked. Typical output from a Strobe scan looks like this:
localhost echo 7/tcp Echo [95,JBP] localhost discard 9/tcp Discard [94,JBP] localhost systat 11/tcp Active Users [89,JBP] localhost daytime 13/tcp Daytime [93,JBP] localhost netstat 15/tcp Netstat localhost chargen 19/tcp Character Generator [92,JBP] localhost ftp 21/tcp File Transfer [Control] [96,JBP] localhost telnet 23/tcp Telnet [112,JBP] localhost smtp 25/tcp Simple Mail Transfer [102,JBP] localhost time 37/tcp Time [108,JBP] localhost finger 79/tcp Finger [52,KLH] localhost pop3 0/tcp Post Office Protocol-Version 3 122 localhost sunrpc 111/tcp SUN Remote Procedure Call [DXG] localhost auth 113/tcp Authentication Service [130,MCSJ] localhost nntp 119/tcp Network News Transfer Protocol 65,PL4As you can see, the information is purely diagnostic in character (for example, there are no probes for particular holes). However, Strobe makes up for this with extensive command-line options. For example, in scanning hosts with large numbers of assigned ports, you can disable all duplicate port descriptions. (Only the first definition is printed.) Other amenities include
Cross Reference: You can find a copy of Strobe, authored by Julian Assange (released 1995), at http://sunsite.kth.se/Linux/system/Network/admin/.
Also, although Strobe does not perform extensive tests on remote hosts, it leaves just as large a footprint as early distributions of ISS. A host that is scanned with Strobe will know it (this will most likely appear as a run of connect requests in the /var/adm/messages file).
SATAN is, admittedly, quite a package. Written for UNIX workstations, SATAN was--at the time of its release--the only X Window System-based security program that was truly user friendly. It features an HTML interface, complete with forms to enter targets, tables to display results, and context-sensitive tutorials that appear when a hole has been found. It is--in a word--extraordinary.
SATAN's authors are equally extraordinary. Dan Farmer and Weitse Venema have both been deeply involved in security. Readers who are unfamiliar with SATAN might remember Dan Farmer as the co-author of COPS, which has become a standard in the UNIX community for checking one's network for security holes. Venema is the author of TCP_Wrapper. (Some people consider TCP_Wrapper to be the grandfather of firewall technology. It replaces inetd as a daemon, and has strong logging options.) Both men are extremely gifted programmers, hackers (not crackers), and authorities on Internet security.
SATAN was designed only for UNIX. It is written primarily in C and Perl (with some HTML thrown in for user friendliness). It operates on a wide variety of UNIX flavors, some with no porting at all and others with moderate to intensive porting.
The package comes tarred and zipped and is available all over the world. As the name of the program (Security Administrator's Tool for Analyzing Networks) suggests, it was written for the purpose of improving network security. As such, not only must one run it in a UNIX environment, one must run it with root privileges.
NOTE: There is a special problem with running SATAN on Linux. The original distribution applies certain rules that result in flawed operation on the Linux platform. There is also a problem with the way the select() call is implemented in the tcp_scan module. Lastly, if one scans an entire subnet at one time, this will result in a reverse fping bomb. That is, socket buffers will overflow. Nevertheless, one site contains not only a nicely hacked SATAN binary for Linux, but also the diff file. (A diff file is a file that is close but not identical to another file. Using the diff utility, one compares the two files. The resulting output consists of the changes that must be made.) These items can be found at ftp.lod.com or one can obtain the diff file directly from Sunsite (sunsite.unc.edu) at /pub/Linux/system/Network/admin/satan-linux.1.1.1.diff.gz.
Cross Reference: You can obtain your copy of SATAN, written by Dan Farmer and Weitse Venema (released April, 1995), at http://www.fish.com.
$dont_use_nslookup = 1;Having resolved all the PATH issues, the user can run a make on the distribution (make IRIX or make SunOS). I suggest watching the compile very closely for errors.
TIP: SATAN requires a little more resources than the average scanner, especially in the area of RAM and processor power. If you are experiencing sluggish performance, there are several solutions you can try. One of the most obvious is to get more RAM and greater processor power. However, if that isn't feasible, I suggest a couple things: One is to kill as many other processes as possible. Another is to limit your scans to 100 hosts or fewer per scan. Lastly, it is of some significance that SATAN has a command-line interface for those without strong video support or with limited memory resources.
Stealth scanners are a new phenomenon, their incidence rising no doubt with the incidence of firewalls on the Net. It's a relatively new area of expertise. So if you test Jakal and find that a few logs appear, don't be unforgiving.
Stealth scanners work by conducting half scans, which start (but never complete) the entire SYN|ACK transaction with the target host. Basically, stealth scans bypass the firewall and evade port scanning detectors, thus identifying what services are running behind that firewall. (This includes rather elaborate scan detectors such as Courtney and Gabriel. Most of these detection systems respond only to fully established connections.)
Cross Reference: Obtain a copy of Jakal, written by Halflife, Jeff (Phiji) Fay, and Abdullah Marafie at http://www.giga.or.at/pub/hacker/unix.
Port: 7 Service: (?) Userid: root Port: 9 Service: (?) Userid: root Port: 11 Service: (?) Userid: root Port: 13 Service: (?) Userid: root Port: 15 Service: (?) Userid: root Port: 19 Service: (?) Userid: root Port: 21 Service: (?) Userid: root Port: 23 Service: (?) Userid: root Port: 25 Service: (?) Userid: root Port: 37 Service: (?) Userid: root Port: 79 Service: (?) Userid: root Port: 80 Service: (?) Userid: root Port: 110 Service: (?) Userid: root Port: 111 Service: (?) Userid: root Port: 113 Service: (?) Userid: root Port: 119 Service: (?) Userid: root Port: 139 Service: (?) Userid: root Port: 513 Service: (?) Userid: root Port: 514 Service: (?) Userid: root Port: 515 Service: (?) Userid: root Port: 540 Service: (?) Userid: root Port: 672 Service: (?) Userid: root Port: 2049 Service: (?) Userid: root Port: 6000 Service: (?) Userid: rootThis utility has a very important function. By finding the UID of the process, misconfigurations can be quickly identified. For example, examine this output. Seasoned security professionals will know that line 12 of the scan shows a serious misconfiguration. Port 80 is running a service as root. It happens that it is running HTTPD. This is a security problem because any attacker who exploits weaknesses in your CGI can run his or her processes as root as well.
I have tried many scanners. IdentTCPscan is extremely fast and as such, it is a powerful and incisive tool (a favorite of crackers). The utility works equally well on a variety of platforms, including Linux, BSDI, and SunOS. It generally comes as a compressed file containing the source code. It is written in C and is very compact. It also requires minimal network resources to run. It will build without event using most any C compiler.
Cross Reference: Obtain a copy of IdentTCPscan, written by David Goldsmith (released February 11, 1996), at http://www.giga.or.at/pub/hacker/unix.
This scanner is of relatively little importance because TFTP is a lame protocol. There isn't much to gain. (Although, if the sysad at that location is negligent, you might be able to obtain the /etc/passwd file. Don't count on it, however. These days, the odds of finding both an open TFTP server and a non-shadowed passwd file on the same machine are practically nil.)
Cross Reference: The documentation of CONNECT is written by Joe Hentzel; according to Hentzel, the script's author is anonymous, and the release date is unknown. Obtain a copy at http://www.giga.or.at/pub/hacker/unix/.
What's extraordinary about FSPScan is that it was written by one of the co-authors of FSP! But then, who better to write such a utility?
Cross Reference: Obtain a copy of FSPScan, written by Wen-King Su (released in 1991), at http://www.giga.or.at/pub/hacker/unix.
Other amenities of XSCAN include the capability to scan multiple hosts in the same scan. These can be entered on the command line as arguments. (And you can specify both hosts and subnets in a kind of mix-and-match implementation.) The source for this utility is included on the CD-ROM that accompanies this book.
Cross Reference: Obtain a copy of XSCAN (release unknown) at http://www.giga.or.at/pub/hacker/unix.
ISS has the distinction of being one of the mainstays of Internet security. It can now be found at thousands of sites in various forms and versions. It is a favorite of hackers and crackers alike, being lightweight and easy to compile on almost any UNIX-based platform. Since the original release of ISS, the utility has become incredibly popular. The development team at ISS has carried this tradition of small, portable security products onward, and SAFEsuite is its latest effort. It is a dramatic improvement over earlier versions.
SAFEsuite consists of several scanners:
This is of some significance. Only recently has NT been recognized by the UNIX community as an acceptable server platform. This may in part be attributed to NT's new C2 security rating. In any event, ISS has broken through the barrier by providing a tested security tool for a large portion of the Microsoft-based community. I consider this a rather far-sighted undertaking on the part of the development team at ISS.
SAFEsuite performs a wide variety of attacks on the specified network. These include diagnostic routines on all of the following services:
According to the folks at ISS:
The /var/adm/messages file records status reports and messages from the system. These naturally include the boot routine and any problems found there, as well as dozens of other processes the user might initiate. (In this case, the /var/adm/messages file will log our server's responses to the SAFEsuite scan.)
NOTE: On some versions of Linux (and indeed, on the majority of UNIX distributions), more valuable logging information can generally be found in /var/adm/syslog than in /var/adm/messages. This is especially so with regard to attempts by users to gain unauthorized access from inside the system.
| Element | Requirement |
| Processor Speed | Not defined |
| RAM | 16MB or better |
| Networking | TCP/IP |
| Privileges | Root or administrator |
| Storage | Approximately 5MB |
| Browser | Any HTML-3 browser client |
| Miscellaneous | Solaris boxes require Motif 1.22+ |
SAFEsuite runs on many platforms, including but not limited to the following:
tar -xvf iss-xxx.tarAfter you untar the archive, you will see a file labeled iss.install. This is a Bourne shell script that will perform the installation. (This mainly involves extracting the distribution disks and the help documentation, which is in HTML format.) Run this file to complete the basic installation process by executing the command sh iss.install. The chief executable is the xiss file, which will launch SAFEsuite in the X Window System, OpenWindows, or any compatible windowing system for UNIX.
If you decide to use SAFEsuite, you might want to take advantage of those incisive options. If so, you need to call the Scanner Configuration window (see Figure 9.1). Some of the options here are similar to options formerly expressed with the command-line interface (such as the outfile, or log file, which contains all information recorded during the scan; this was formerly assigned with the -o option). Other options are entirely new, such as the option for specifying a Web browser.
Figure 9.1.
The SAFEsuite configuration screen.
Special Features The options to specify additional ports is particularly interesting. So is the capability to add modules. SAFEsuite appears to be quite extensible. Thus, if you hack specialized code for probing parts of the system not covered by SAFEsuite, you can include these modules into the scan (as you can with Farmer and Venema's SATAN).
NOTE: The Web browser option isn't really an option. To read the unabridged manual that comes with SAFEsuite, you must specify a browser. That is, if the user does not specify a browser, the Help option in the main menu window will not work. (An error message is produced, informing you that you have not chosen a browser.) If there is a reason why you don't want to specify a browser at that point--or if the machine you are using does not have one--you can still view the entire tutorial and manual on another machine. Simply transport all HTML files into a directory of your choice, start a browser, and open index.html. The links will work fine locally.
TIP: Even if you don't write your own security tools, you can patch in the code of others. For example, there are many nonestablishment scanners out there that perform specialized tasks. There is no reason why these tools cannot be solidly integrated into the SAFEsuite scan.
NOTE: The SAFEsuite program includes network maps, which are an ingenious creation (one that Farmer and Venema had intentions of adding to SATAN). The network map is a wonderful way to quickly isolate problem machines or configurations on your network. These maps provide a graphical representation of your network, visually highlighting potential danger spots. Used in conjunction with other network architecture tools (many which are not particularly related to security), products like SAFEsuite can help you to quickly design safe network topology.
Cross Reference: For more information about the purchase, use, or configuration of SAFEsuite, contact ISS at its Web page (http://ISS).
NOTE: For the truly curious, I was running SAFEsuite through a standard configuration of MIT's X Window System. The X Window manager was FVWM.
# Rlogin Binding to Port # Connected to Rlogin Port # Trying to gain access via Rlogin 127.0.0.1: ---- rlogin begin output ---- 127.0.0.1: ---- rlogin end output ---- # Rlogin check complete, not vulnerable.In other areas, however, the SamsHack server was vulnerable to attack. These vulnerabilities were critical. Take a close look at the following log entry:
# Time Stamp(555): Rsh check: (848027962) Thu Nov 14 19:19:22 # Checking Rsh For Vulnerabilities # Rsh Shell Binding to Port # Sending command to Rsh 127.0.0.1: bin/bin logged in to rsh 127.0.0.1: Files grabbed from rsh into `./127.0.0.1.rsh.files' 127.0.0.1: Rsh vulnerable in hosts.equiv # Completed Checking Rsh for VulnerabilityYou'll see that line 6 suggests that some files were grabbed and saved. Their output was sent to a file called 127.0.0.1.rsh.files. Can you guess what file or files were saved to that file? If you guessed the /etc/passwd file, you are quite correct. Here are the contents of 127.0.0.1.rsh.files:
root:bBndEhmQlYwTc:0:0:root:/root:/bin/bash bin:*:1:1:bin:/bin: daemon:*:2:2:daemon:/sbin: adm:*:3:4:adm:/var/adm: lp:*:4:7:lp:/var/spool/lpd: sync:*:5:0:sync:/sbin:/bin/sync shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown halt:*:7:0:halt:/sbin:/sbin/halt mail:*:8:12:mail:/var/spool/mail: news:*:9:13:news:/usr/lib/news: uucp:*:10:14:uucp:/var/spool/uucppublic: operator:*:11:0:operator:/root:/bin/bash games:*:12:100:games:/usr/games: man:*:13:15:man:/usr/man: postmaster:*:14:12:postmaster:/var/spool/mail:/bin/bash nobody:*:-1:100:nobody:/dev/null: ftp:*:404:1::/home/ftp:/bin/bash guest:*:405:100:guest:/dev/null:/dev/nullFTP also proved to be vulnerable (although the importance of this is questionable):
127.0.0.1: ---- FTP version begin output ---- SamsHack FTP server (Version wu-2.4(1) Tue Aug 8 15:50:43 CDT 1995) ready. 127.0.0.1: ---- FTP version end output ---- 127.0.0.1: Please login with USER and PASS. 127.0.0.1: Guest login ok, send your complete e-mail address as password. 127.0.0.1: Please login with USER and PASS. 127.0.0.1: ANONYMOUS FTP ALLOWED 127.0.0.1: Guest login ok, access restrictions apply. 127.0.0.1: "/" is current directory. 127.0.0.1: iss.test: Permission denied. 127.0.0.1: iss.test: Permission denied. (Delete) 127.0.0.1: Entering Passive Mode (127,0,0,1,4,217) 127.0.0.1: Opening ASCII mode data connection for /bin/ls. 127.0.0.1: Transfer complete. 127.0.0.1: Entering Passive Mode (127,0,0,1,4,219) 127.0.0.1: Opening ASCII mode data connection for /etc/passwd (532 bytes). 127.0.0.1: Transfer complete. 127.0.0.1: Files grabbed via FTP into ./127.0.0.1.anonftp.files 127.0.0.1: Goodbye.As you might have surmised, the passwd file for FTP was grabbed into a file. Thus, in this chapter, we have identified at least three serious security weaknesses in SamsHack.net:
I have included the entire scan log on the CD-ROM that accompanies this book. Printing it here would be unreasonable, as it amounts to over 15 pages of information.
You have just seen the basics of scanning a single host. But in reality, a cracker might scan as many as 200 hosts in a single evening. For such widespread activity, more resources are required (greater bandwidth, more RAM, and a more powerful processor). But resources are not the cracker's only concern; such a scan leaves a huge footprint. We've seen this scan from the cracker's perspective. Now, let's look at it from the victim's perspective.
On November 10, 1996, I conducted a scan identical to the one shown previously, which was performed on November 14, 1996. The only difference between the two scans is that on the November 10th scan, I employed not one but several scanners against the SamsHack server. Those scans and their activities were reported to the system to the file /var/adm/messages. Take a look at the output:
Nov 10 21:29:38 SamsHack ps[159]: connect from localhost Nov 10 21:29:38 SamsHack netstat[160]: connect from localhost Nov 10 21:29:38 SamsHack in.fingerd[166]: connect from localhost Nov 10 21:29:38 SamsHack wu.ftpd[162]: connect from localhost Nov 10 21:29:38 SamsHack in.telnetd[163]: connect from localhost Nov 10 21:29:39 SamsHack ftpd[162]: FTP session closed Nov 10 21:29:39 SamsHack in.pop3d[169]: connect from localhost Nov 10 21:29:40 SamsHack in.nntpd[170]: connect from localhost Nov 10 21:29:40 SamsHack uucico[174]: connect from localhost Nov 10 21:29:40 SamsHack in.rlogind[171]: connect from localhost Nov 10 21:29:40 SamsHack in.rshd[172]: connect from localhost Nov 10 21:29:40 SamsHack telnetd[163]: ttloop: read: Broken pipe Nov 10 21:29:41 SamsHack nntpd[170]: localhost connect Nov 10 21:29:41 SamsHack nntpd[170]: localhost refused connection Nov 10 21:29:51 SamsHack ps[179]: connect from localhost Nov 10 21:29:51 SamsHack netstat[180]: connect from localhost Nov 10 21:29:51 SamsHack wu.ftpd[182]: connect from localhost Nov 10 21:29:51 SamsHack in.telnetd[183]: connect from localhost Nov 10 21:29:51 SamsHack in.fingerd[186]: connect from localhost Nov 10 21:29:51 SamsHack in.pop3d[187]: connect from localhost Nov 10 21:29:52 SamsHack ftpd[182]: FTP session closed Nov 10 21:29:52 SamsHack in.nntpd[189]: connect from localhost Nov 10 21:29:52 SamsHack nntpd[189]: localhost connect Nov 10 21:29:52 SamsHack nntpd[189]: localhost refused connection Nov 10 21:29:52 SamsHack uucico[192]: connect from localhost Nov 10 21:29:52 SamsHack in.rshd[194]: connect from localhost Nov 10 21:29:52 SamsHack in.rlogind[193]: connect from localhost Nov 10 21:29:53 SamsHack login: ROOT LOGIN ON tty2 Nov 10 21:34:17 SamsHack ps[265]: connect from pm7-6.pacificnet.net Nov 10 21:34:17 SamsHack netstat[266]: connect from pm7-6.pacificnet.net Nov 10 21:34:17 SamsHack wu.ftpd[268]: connect from pm7-6.pacificnet.net Nov 10 21:34:22 SamsHack ftpd[268]: FTP session closed Nov 10 21:34:22 SamsHack in.telnetd[269]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack in.fingerd[271]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack uucico[275]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack in.pop3d[276]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack in.rlogind[277]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack in.rshd[278]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack in.nntpd[279]: connect from pm7-6.pacificnet.net Nov 10 21:34:28 SamsHack telnetd[269]: ttloop: read: Broken pipe Nov 10 21:34:28 SamsHack nntpd[279]: pm7-6.pacificnet.net connect Nov 10 21:34:28 SamsHack nntpd[279]: pm7-6.pacificnet.net refused connection Nov 10 21:34:33 SamsHack rlogind[277]: Connection from 207.171.17.199 on illegal portThe first thing I want you to notice is the time. The first line of this log excerpt reports the time as 21:29:38. The last line of the scan reports 21:34:33. Thus, the entire range of activity occurred within a five-minute period. Next, I want you to take a good look at what's happening here. You will see that nearly every open, available port has been attacked (some of them more than once). And, on at least one occasion, the IP address from which the attack originated appears clearly within the log (specifically, on the last line of the small snippet of log I have provided). The line appears as
Nov 10 21:34:33 SamsHack rlogind[277]: Connection from 207.171.17.199 on illegal portIt is quite obvious that any system administrator looking for attacks like this one needn't look far. Keep in mind that in this example, I was not running any special logging utilities or wrappers. Just plain, old logging, which is on by default in a factory install.
So the average system administrator needn't do more than search the /var/adm/message file (or its equivalent) for runs of connection requests. However, you will be surprised to know that an overwhelming number of system administrators do not do this on a regular basis.
This is the main reason that certain platforms, like the Macintosh platform, have thus far seen fewer intrusions than UNIX-based operating systems. The fewer services you actually run, the less likely it is that a hole will be found. That is common sense.
Equally, many platforms other than UNIX do support extensive TCP/IP. AS/400 is one such platform. Microsoft Windows NT (with Internet Information Server) is another. Certainly, any system that runs any form of TCP/IP could potentially support a wide range of protocols. Novell NetWare, for example, has long had support for TCP/IP.
It boils down to this: The information you will reap from scanning a wide variety of operating systems depends largely on the construct of the /etc/services file or the targeted operating system's equivalent. This file defines what ports and services are available. This subject will discussed later, as it is relevant to (and implemented differently on) varied operating systems. In Chapter 18, "Novell," for example, I examine this file and its uses on the Novell NetWare platform.
port: 9 discard Service available port: 13 daytime Service available port: 21 ftp Service available port: 23 telnet Service available port: 25 smtp Service available port: 37 time Service available port: 79 finger Service available port: 80 http Service available port:110 pop3 Service available port:111 portmap Service available port:512 exec Service available port:513 login Service available port:514 shell Service available port:540 uucp Service available
Figure 9.3.
The Network Toolbox Options panel.
5. The last step is to actually scan the targeted host. This
is done by choosing the Scan button shown in Figure 9.5.
The port scanner in Network Toolbox is fast and accurate. The average scan takes less than a minute. I would characterize this as a good product. Moreover, it provides ports of several other UNIX utilities of interest.
The information gleaned using this utility is quite similar to that obtained using Strobe. It will not tell you the owner of a process, nor does the Network Toolbox port scanner try doors or windows. (In other words, it makes no attempt to penetrate the target network.) However, it is valuable because it can quickly determine what processes are now running on the target.
Internet security is a constantly changing field. As new holes are discovered, they are posted to various mailing lists, alert rosters, and newsgroups. Most commonly, such alerts end up at CERT or CIAC. Crackers and hackers alike belong to such mailing lists and often read CERT advisories. Thus, these new holes become common knowledge often minutes or hours after they are posted.
As each new hole is uncovered, capabilities to check for the new hole are added to existing scanners. The process is not particularly complex. In most cases, the cracker need only write a small amount of additional code, which is then pasted into the existing source code of his or her scanner. The scanner is then recompiled and voilà! The cracker is ready to exploit a new hole on a wide scale. This is a never-ending process.
System administrators must learn about and implement scanners. It is a fact of life. Those who fail to do so will suffer the consequences, which can be very grave. I believe scanners can educate new system administrators as to potential security risks. If for no other reason than this, scanners are an important element of Internet security. I recommend trying out as many as possible.
© Copyright, Macmillan Computer Publishing. All rights reserved.